HPAVC/HPAVC CD-ROM.iso/pc/MS_ARCAD.ZIP/ARC5_3.CHP

Text File | 1993-06-15 | 5.5 KB | 128 lines

%
#EF
#T15,1,Chapter 5     General Design Considerations     Pg. 11
#HS,1,4,80,25,11,1
#C4,R5
                 ~W~IInformation and Implementation Hiding~Y~I

Since proper programs are composed of a combination of selection,
iteration, sequence, and recursion, we see that our games will be
completely modular and that there is no room in our programs for GOTO's.
I keep harping on that because I've seen how jumps in and out of modules
can destroy the modifiability of a program.

#WN
#C4,R23
In good, modular programs, the implementation is hidden between modules.
#EL,23
#C4,R22
In good, modular programs, the implementation is hidden between modules.
Information is also as well hidden as possible. Implementation hiding is
#ES,1,22,80,23
#C4,R21
In good, modular programs, the implementation is hidden between modules.
Information is also as well hidden as possible. Implementation hiding is
when nothing outside a module 'knows" anything about the way the module
#ES,1,21,80,23
#C4,R20
In good, modular programs, the implementation is hidden between modules.
Information is also as well hidden as possible. Implementation hiding is
when nothing outside a module 'knows" anything about the way the module
is written.
#ES,1,20,80,23
#C4,R19
In good, modular programs, the implementation is hidden between modules.
Information is also as well hidden as possible. Implementation hiding is
when nothing outside a module 'knows" anything about the way the module
is written.
#ES,1,19,80,23
#C4,R18
In good, modular programs, the implementation is hidden between modules.
Information is also as well hidden as possible. Implementation hiding is
when nothing outside a module 'knows" anything about the way the module
is written.
#ES,1,18,80,23
#C4,R17
In good, modular programs, the implementation is hidden between modules.
Information is also as well hidden as possible. Implementation hiding is
when nothing outside a module 'knows" anything about the way the module
is written.
#ES,1,17,80,23
#C4,R16
In good, modular programs, the implementation is hidden between modules.
Information is also as well hidden as possible. Implementation hiding is
when nothing outside a module 'knows" anything about the way the module
is written.
#ES,1,16,80,23
#C4,R15
In good, modular programs, the implementation is hidden between modules.
Information is also as well hidden as possible. Implementation hiding is
when nothing outside a module 'knows" anything about the way the module
is written.
#ES,1,15,80,23
#C4,R14
In good, modular programs, the implementation is hidden between modules.
Information is also as well hidden as possible. Implementation hiding is
when nothing outside a module 'knows" anything about the way the module
is written.
#ES,1,14,80,23
#C4,R13
In good, modular programs, the implementation is hidden between modules.
Information is also as well hidden as possible. Implementation hiding is
when nothing outside a module 'knows" anything about the way the module
is written.

#WN
%
#EF
#T15,1,Chapter 5     General Design Considerations     Pg. 12
#HS,1,4,80,25,11,1
#C4,R5
~Y~IHere's an example. If I want to give my program a nice menued user
interface, I'm going to have to write some routines that will pop up a
horizontal menu across the top of the screen, as well as functions to do
vertical menus. ~SI might even add dialog boxes and help windows.~s ~G~ISince
these functions are conceptually related, I would group them into a single
C source file. ~Y~II would need a set of functions that perform the required
operations on a menu, so I would make a function called ~W~Icreate_menu()~Y~I,
and another called ~W~Idisplay_menu()~Y~I, etc. All of these would be together
in a file I'd call ~W~IMENU.C~Y~I.

#WN
The functions ~W~Icreate_menu()~Y~I and ~W~Idisplay_menu()~Y~I would be part of a group of
functions that would form the interface into ~W~IMENU.C~Y~I. There may be other
functions in there which provide support to the interface functions. For
instance, maybe I have a function in ~W~IMENU.C~Y~I called ~W~Iinit_menu()~Y~I. This
function is called by ~W~Icreate_menu()~Y~I, but by ~M~Ino other function~Y~I. It would be
nice if we could help hide the implementation of menus by preventing any
other file from being able to call ~W~Iinit_menu()~Y~I. We can do this by declaring
~W~Iinit_menu()~Y~I to be of storage class |static|. We'll see examples of how this
is done in the game that we'll write.

#WP
%
#EF
#T15,1,Chapter 5     General Design Considerations     Pg. 13
#HS,1,4,80,25,11,1
#C4,R5
~Y~IWhy is it important to hide the implementation? The primary reason is to
increase the maintainability of the program. If for some reason I need to
change the way that menus are implemented, I can easily do so if no
functions in files outside ~W~IMENU.C~Y~I make a direct reference to the way menus
are implemented. If all functions outside ~W~IMENU.C~Y~I are forced to access the
implementation of a menu through the interface of functions, then we can
change the way menus are implemented. As long as the interface doesn't
change, then the other functions won't be affected.

#WN
Information hiding is similar to implementation hiding. If I have a group
of related data, it's nice to put it together into a structure variable
and provide functions and macros that do operations on the data as a unit.

#WN
Both information hiding and implementation hiding will be demonstrated in
the game, so you'll be able to see what I mean before you need to do it
yourself.

#WP
#X